REMARKS 

The above Amendments and these Remarks are in reply to the Office Action mailed 
January 15,2004. 

Currently, claims 1- 39, 41 -51 are pending. Applicants have amended claims 1, 9, 15, 18, 
28, and 35 and cancelled claim 40. Applicants respectfully request reconsideration of claims 1-39 
and 41-51. 

I. Summary of the Examiner's Objections 

Claim 1 was rejected under 35 USC 112, second paragraph, as being indefinite for failing to 
particularly point out and distinctly claim the subject matter which applicant regards as the invention. 

Claims 1-3, 5-7, 9-13, 22-25 and 27 were rejected under 35 USC 102(b) as being anticipated 
byKrause (U.S. 5,950,206). 

Claims 4, 35 and 41-51 are rejected under 35 USC 1 03(a) as being unpatentable over Krause 
(US 5,950,206) in view of Ito (US 5,761,674). 

Claims 14-21, 26, 28-30, 33, 36, 37 and 40 were rejected under 35 USC 103(a) as being 
unpatentable over Krause (US 5,950,206) in view of Bentley et al. (US 6,063,128). 

Claims 31, 32, 34, 38 and 39 were rejected under 35 USC 103(a) as being unpatentable over 
Krause (US 5,950,206) in view of Bentley et al. (US 6,063,128) further in view of Ito (US 
5,761,674). 

II. Summary of the Amendments 

Currently, claims 1- 39, 41 -51 are pending. Applicants have amended claims 1,9, 15, 18, 
28, and 35 and cancelled claim 40. Applicants respectfully request reconsideration of claims 1-39 
and 41-51. 
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III. Remarks 

A. Rejection Under 35 U.S.C. §112. 

It is respectfully submitted that the rejection of claim 1-8 and 15-21 under 35 U.S.C. §112, 
second paragraph, is now moot. The language "allocation value" has been deleted from the claim. 

B. Rejection of Claims 1-8. 

It is respectfully submitted claims 1 - 3 and 5 - 8 1 are not anticipated by Krause, and that 
claims 4 is not obvious in view of Krause and Ito. Krause does not show each and every feature of 
the claimed invention. 

Krause does not disclose ' . . .at least a first item specification template ..." as defined in 
claim 1 . Indeed, Krause does not disclose a "template" or any tools with respect to the use of 
templates. It is noted that other claim language (specifically claims 15 "template creation tool" 
and 18 "defining a specification template") that the Examiner did not reference Krause alone 
when referring to template creation methods and tools. Hence, it is submitted that such feature 
could not be found in Krause and as such, Krause cannot anticipate claim 1 . 

In addition, Krause does not disclose the feature of the claimed invention calling for: 

An data structure for an asset management system ... the asset including a plurality 
of physical items contained in the asset... 

Krause clearly discloses a "Document Information Database" (Krause, title). There is no 
disclosure in Krause that the construction projects tracked in the information database of documents 
contain "items" as the term "items" is used in claims 1-8. In particular, though the Examiner has 
referenced Col. 4, lines 56- 62 as disclosing "a plurality of data fields describing an item" and, as 
understood, an attribute value, it is respectfully submitted that this section of Krause discloses only a 
method for searching documents in the database. The section of Krause reads as follows: 

1 it is respectfully noted that claim 8 was not listed in the heading of the rejection based on 35 U.S.C. §102, but is 
noted in the text of the rejection. It is therefore understood to be included in the rejection under Section 102(b). 
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Once authorized, the member can use the input devices 1 6 to select one or more key 
words in an instruction set 54. The key words relate to the type of project in order to limit 
the information viewed to projects of interest to the member. For example, the member 
may only be interested in bidding on labor and/or material related to masonry. By 
selecting "masonry" as a key word, only projects having "masonry" in the stored 
information will be displayed on the monitor 14 when the database 44 is searched. An 
example of a project description including the key word "masonry" is shown in the 
FIG. 4 which is a project information report that can be printed by the member. The 
key words available also include CSI numbers. An example of a project description 
including CSI numbers as key words is shown in the FIG. 5 which is another project 
information report that can be printed by the member, (emphasis supplied). 

This section refers to "key words" used to select information (documents) about the project. This is in 
clear contrast to a system which contains "physical items contained in the asset". 

Additionally, Krause does not disclose ". . .a plurality of data values comprising a specification 
for at least one item" as defined in claim 1 . 

As noted in the claim language, "items" are "physical" and are "contained in the asset". 
Hence, "documents" searched using key words input to a search mechanism, as taught by Krause, are 
not equivalent to "items" as defined in the claim. Hence, Krause does not teach including "...a 
plurality of data values comprising a specification. . ." as defined in claim 1. 

To the extent that the Examiner's reference to Bentley et al. in calling out template usage (in 
claims 15 and 18), it is respectfully submitted that Bentley et al. does not disclose an "item 
specification template." 

The term "item specification" is defined in the specification: 

Item Specification: The detail information about objects involved in building the parts and 
components of something. An example of an item would be a desk; an example of the item 
specification would be the description of the desk (height, width, depth, color, material, and so forth), 
its manufacturer(s), costs, delivery options, catalog numbers, and so forth, (p. 16, line 7) 
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The context of a "template" is also defined in the specification: 

Item Type: A template for creating item specifications for broad categories of items. For 
example: a user might have an item type of "office furniture " this item type forms a template a user 
would use to create the many item specifications for various desks required, (p. 16, line 13) 

It is respectfully submitted that one of average skill in the art would not be led by Bentley et 
al. to provide ". . .at least a first item specification template. . Bentley et al.'s item 58, referenced 
by the Examiner, is a template used to create a generic class as a feature of a computer programming 
language. As noted in Bentley et al.'s specification: 

A template 58 provides a flexible programming technique for declaring classes 54 and 
interfaces 56. A template 58 is a declaration of a "shell class" or "shell interface" with some of 
the type information parameterized (i.e. not filled in). The parameterized type information is 
then "filled in" during compile-time according to other source code. For example, 'template 1 ' 
shown in FIG. 5 defines a shell class that has been filled in a first time to create "class IT, 
and a second time to create a 'class T2\ Accordingly, while 'class TT and 'class T2' are 
structurally similar, the actual components represented by each class 54 may be quite 
different. 

Templates 58 are typically used for creating container classes. Consider a class 54 that 
manages lists of objects 52. Without templates 58, a programmer must either create 
implementations of the list for every type of object 52 that can appear in the list, or must 
implement the list class 54 in a way that bypasses type safety verifying algorithms typically 
present in a compiler 55. Templates 58 allow a programmer to implement a shell just once in 
the source code, and to let the compiler 55 make the template 58 work for all of the intended 
uses. (Col. 15, line 20-41) 

Hence, Bentley et al. defines templates in terms of their use in computer programming, not in terms 

of a definition for a physical item to be used in a database of items. One of average skill in the art 

would not look to the computer object oriented computer modeling application of Bentley et al. to 

find the use of templates relevant to the characterization of "items" in the present invention. 

Finally, Krause does not disclose the invention as defined in claims 1 including a data 
structure wherein such "values" comprise: 

at least one attribute value; and 

at least one component value associating the item with a second item specification. 



Attorney Docket No.: TRIRG-01001 USO 
trirg/ 1 00 1/1 001. remarks 



-13- 



As noted above, the "values" cited by the Examiner in Krause are, in fact, reference search terms for 
use by the document management system in Krause to retrieve relevant documents. 
In contrast, an "attribute" is specifically described in the pending application: 

Attribute: A quality of characteristic inherent in or ascribed to an item specification, (p. 15, line 9) 

Likewise, a "component" is specifically described in the pending application: 

A component is an existing Item Specification associated to another item 
specification; together, they make up a whole item or an assembly. An Item Specification can 
have multiple components, (page 15, line 25) 

Neither an "attribute value" nor a "component" are disclosed in Krause. The cited portion of the 
Krause reference alleged by the Examiner to support the disclosure of an "attribute value" is, as 
described above, a reference to "searching for construction projects" which include information 
about the project, not items in the project. The section alleged to contain a component value, in 
"fig. 6" again relate to searching for documents in the project, not specific information on items in 
the project. Moreover, the data fields of Figure 6 in Krause and the cited text at Col. 4 lines 56 - 62 
of the specification are both generally referring to the same information. Neither defines component 
values which would meet the limitation of". . .at least one component value associating the item with 
a second item specification. . 

For the reasons set forth above, it is respectfully submitted that Krause does not anticipate the 
invention as defined in claims 1 - 8. M A rejection for anticipation under section 102 requires that 
each and every limitation of the claimed invention be disclosed in a single prior art reference." In re 
Paulsen, 30 F.3d 1475, 31 USPQ2d 1671 (Fed. Cir. 1994). Since each and every limitation is not 
found in Krause, claims 1 - 8 are respectfully submitted to be allowable over Krause. 

B. Rejection of Claims 9 - 27 . 

It is respectfully submitted that claims 9 ~ 1 3, 22 - 25 and 27 are not anticipated by Krause, 
nor are claims 14-21 and obvious over Krause in view of Bentley et al. 



Attorney Docket No.: TRIRG-01001 USO 
trirg/1001/1001. remarks 



- 14- 



In particular, Krause does not disclose each an every feature of applicant's invention, and in 
particular with respect to claim 9 does not disclose: 

A method for constructing data concerning item specifications in a system for 
managing an asset, the asset including a plurality of items 

There is no disclosure in Krause that the construction projects tracked in the information database of 
documents contain "item specifications" as the term is used in claims 9 - 27. As noted above, 
Krause teaches a document management system. 

Moreover, Krause does not disclose alone, or in combination with Bentley et al., the step 
defined in claim 9 of "...defining at least one item specification template." 

As noted above, Krause teaches a document management system for construction projects. 
The language of . . defining at least one item specification template" is similar to that which 
appeared in claim 1 8 prior to this Amendment. Claim 1 8 was rejected only under 35 U.S.C. § 103 
and hence it is submitted that claim 9 as amended cannot be anticipated by Krause. The section cited 
by the Examiner as supporting the step of "defining a template" is item "58, fig. 5" of Bentley et al. 
As noted above, the use of the term "template" in Bentley et al. is in the sense of its use in the object 
oriented programming sense: 

In programming, a template is a generic class or other unit of source code that can be used as 
the basis for unique units of code. In C++ , an object-oriented computing language, there are 
Standard Template Libraries from which programmers can choose individual template classes 
to modify. The Microsoft Foundation Class Library (MFCL) is an example, (see, 
http://searchwebservices. tech target. com/sDefin ition/0, , sid26jgci2 13117,00. html) 

The "template" in Bentley et al. is not an "item specification" template as such term is used and 
understood in the claim. There is no teaching or suggestion of providing a definition for an "item", 
which is a part of an asset, under the teachings of Bentley et al. 

Hence, one of average skill in the art would not be led by the teachings of Bentley et al. in 
combination with those of Krause to the claimed invention. Moreover, the motivation for combining 
the references is not present, nor is such motivation provided by the Examiner. In particular, Krause 
deals with document management while Bentley et al. with a computer modeling application. One 
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of average skill in the art would not look to the computer system level teachings of an object oriented 
programming system of Bentley et al. to derive object modeling aspects in a document management 
system such as that described in Krause. Krause discloses a fairly simple categorization scheme for 
construction documents, and Bentley et al. discloses an object oriented modeling system. 

Krause does not teach the feature of the invention defined in claim 9 including the step of: 

receiving a plurality of data values, . . . .wherein the plurality of data values comprise a 
specification for an item and each data field of the specification describes an attribute of the 
item, and 

The term "specification" has a meaning in the context of the application and claims. The cited 
portion of the Krause reference alleged by the Examiner to support the disclosure of an "attribute 
value" is, as described above, a reference to "searching for construction projects" which include 
information about the project, not items in the project. (Krause, col4, lines 56 - 62). As such, there 
is no teaching of a step of "receiving" as defined in claim 9. 

Because Krause does not disclose defining a specification, nor "receiving a plurality of data 
values", it does not disclose: 

storing the specification into a database on a computer system 

Hence, for the reasons set forth above, it is respectfully submitted that claims 9 - 1 3, 22 - 25 
and 27 are not anticipated by Krause, nor are claims 9 - 27 and obvious over Krause in view of 
Bentley et al. 

C. Rejection of Claims 28 - 34. 

It is respectfully submitted that claims 28 - 30 and 33 are not obvious over Krause in view of 
Bentley et al, and claims 31 and 34 are not obvious over Krause in view of Bentley et al. further in 
view of Ito. 
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In particular, it is respectfully submitted that neither Krause alone nor in combination with 
Bentley et al. nor Ito, provides teachings sufficient to render the invention obvious to one of average 
skill in the art. Claim 28 calls for a feature of the claimed invention which includes a: 

method of allowing users to manage an asset, the asset including a plurality of 
items having features and attributes, 

As noted above, an "item" in an "asset" is distinct from a "document" as taught by the Krause 
system. For the reasons set forth above, it is respectfully submitted that there is no teaching of a 
method to manage an "asset" which includes a plurality of "items." In addition, neither Krause alone 
nor in combination with Bentley et al. nor Ito discloses a method as defined in claim 28 including the 
step of: 

providing, responsive to a client request, an item specification management 
toolset including at least one template definition application; 

As noted above, neither Krause nor Bentley et al. teaches an "item specification" and hence neither 
teaches a tool set for managing item specification. The Examiner has cited column 48, lines 38-49 
of Bentley et al. as teaching an item specification management toolset including a template definition 
application. This section reads as follows: 

Preferably, the CMS 10 of the present embodiment allows a schema developer to define a 
built-in property by declaring a pair of methods which mediate "get" and "set" access to the 
value of the property. Accordingly, property access requests may be forwarded to such 
access methods. Property access methods may also be called directly. A schema developer 
may then publish methods for built-in properties by using a special naming convention, as is 
more fully described in SOMObjects Developer Toolkit: Users Guide (Version 2.0), hereby 
incorporated by reference. The method names may then be parsed to determine the name of 
the property and to identify the get and set access methods. 

At most, this section defines a third party application for developing classes of objects. The toolset 
described therein refers to the System Object Model toolkit for building objects in accordance with a 
well defined model. In particular, the SOM (System Object Model) is a library packaging 
technology that enables languages to share class libraries regardless of the language they were 
written in. This ability to share class libraries between various object oriented languages solves many 
interoperability and re-use problems between object oriented and non object oriented languages as 
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well. SOM objects are derived from a root object which defines the essential behavior common to all 
SOM objects. Factory methods are used to create SOM objects at run time. These factory methods 
are invoked on a class object, in the SOM run-time. (See, http://www.obis.com/x3h7/som.htm ) 
Claim 28 now includes a limitation calling for: 

providing at least one item template including a plurality of data fields; and 

As noted above, neither Krause nor Bentley et al. teach a template as defined in the present 
claims. 

Finally, neither Krause alone nor in combination with Bentley et al. nor Ito discloses: 

receiving data from the client including at attribute value and at least one component 
value for at least one item and storing said values in a database. 

As noted above, a component value as used in the present application has a specific meaning. 
Neither an "attribute value" nor a "component" are disclosed in Krause. The cited portion of the 
Krause reference alleged by the Examiner to support the disclosure of an "attribute value" is, as 
described above, a reference to "searching for construction projects" which include information 
about the project, not items in the project. 

D. Rejection of Claims 35 - 39 and 41 - 51. 

It is respectfully submitted that claims 35 and 41 - 5 1 are not obvious over Krause in view of 
Ito, claims 36-37 are not obvious over Krause in view of Bentley et al., and claims 38 - 39 are not 
obvious over Krause in view of Bentley et al. further in view of Ito. 

In particular, the prior art fails to teach one of average skill in the art certain limitations of the 
invention, and even if such features were taught, one of average skill in the art would not be 
motivated to combine the references in the manner suggested by the Examiner. Moreover, the 
motivation for combining the references is lacking in the rejection and in the prior art. 
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In particular, Krause, Bentley et al. and Ito fail to teach the feature, defined in claim 35, of 
". . .a data store for item specification data". As noted above, the terms "item" and "specification" 
have particular meaning, and for the reasons set forth above, it is respectfully submitted that the prior 
art does not teach a system or data store including item specifications. 

In addition, the prior art fails to teach the feature of the invention defined in claim 35 
calling for : 

at least one item template provided on the host computer, the template including a plurality of 
data fields; 

The use of the term "template" in the prior art has a significantly different meaning than in the 
present claims. The only similarity is in the generic use of the term as being a guide. 
Finally, the prior art fails-to teach the feature of the invention calling for: 

a data input toolset comprising at least an item specification creation tool, item type 
manager and an item specification manager. 

Each of the foregoing limitations is present in claim 35 and claims 36-39 and 41 -5 1 by their 
dependence on claim 35. Hence, for the reasons set forth above with respect to claims 1 , 9 and 28, it 
is respectfully submitted that claims 35 - 39 and 41 - 51 are not anticipated by nor obvious in view 
of the cited prior art. 

Based on the above amendments and these remarks, reconsideration of claims 1 -39 and 41-51 
is respectfully requested. 

The Examiner's prompt attention to this matter is greatly appreciated. Should further 
questions remain, the Examiner is invited to contact the undersigned attorney by telephone. 

Enclosed is a PETITION FOR EXTENSION OF TIME UNDER 37 C.F.R. § 1.136 for 
extending the time to respond up to and including today, July 15, 2004. 

The Commissioner is authorized to charge any underpayment or credit any overpayment to 
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Deposit Account No. 501826 for any matter in connection with this response, including any fee for 
extension of time, which may be required. 



Vierra Magen Marcus Harmon & DeNiro LLP 

685 Market Street, Suite 540 

San Francisco, California 94105-4206 

Telephone: (415) 369-9660 

Facsimile: (415)369-9665 



Respectfully submitted, 




Reg. No. 33,809 
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